home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14188 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB
  1. Path: news.ld.centuryinter.net!usenet
  2. From: dongayle@centuryinter.net (Don & Gayle Peterson)
  3. Newsgroups: comp.lang.c,comp.unix.programmer
  4. Subject: Re: Q: '\n' character
  5. Date: Fri, 12 Apr 1996 05:04:27 GMT
  6. Organization: Picture Perfect
  7. Message-ID: <4kko80$8np@news.ld.centuryinter.net>
  8. References: <4kj66f$k0o@ren.cei.net> <4kjh25INNf2e@anvil.ugrad.cs.ubc.ca>
  9. NNTP-Posting-Host: anxp2.mn.centuryinter.net
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) wrote:
  13.  
  14. >In article <4kj66f$k0o@ren.cei.net>,  <james lemley> wrote:
  15. >>>>>Is there a function or some sort of way that I could remove '\n'
  16. >>>>>charecter form the end of the string. 
  17. >>
  18. >>fgets(buffer, file); 
  19. >>buffer[strlen(buffer)-1]=0;  
  20. >>
  21. >>
  22. >>It may not be the fastest, but it is darned near the easiest. 
  23.  
  24. >It's also completely incorrect. What if there is no newline at the end?
  25.  
  26. >This is just part of a bullshit solution to the original problem which is to
  27. >print lines from two files side by side. 
  28.  
  29. >In implementing the solution, there is no need to build a string and then try
  30. >to remove a trailing newline.
  31.  
  32. >Here is one solution that doesn't use its own buffers at all, though admittedly
  33. >it does once call feof() on the file streams before anything is read from them
  34. >for the sake of keeping everything in one tidy loop, rather than splitting
  35. >into cases:
  36.  
  37.  
  38. >#include <stdio.h>
  39.  
  40. >void concatprint(FILE *f1, FILE *f2)
  41.  
  42. >/*
  43. > * read lines from f1 and f2 simultaneously, and print them side by side
  44. > * f1 and f2 must be valid streams open for reading.
  45. > */
  46.  
  47. >{
  48. >        int c;
  49.  
  50. >        do {
  51. >                if (!feof(f1) && !ferror(f1)) 
  52. >                        while ((c = getc(f1)) != '\n' && c != EOF)
  53. >                                putchar(c);
  54. >                if (!feof(f2) && !ferror(f2)) 
  55. >                        while ((c = getc(f2)) != '\n' && c != EOF)
  56. >                                putchar(c);
  57. >                putchar('\n');
  58. >        } while ((!feof(f1) && !ferror(f1)) || (!feof(f2) && !ferror(f2)));
  59. >}
  60.  
  61. >This is a complete, tested solution to the original posting, unlike some of the
  62. >half-baked, unverified remarks that were posted in response, which completely
  63. >miss the central problem anyway. There were calls for strtok(), fgets() and
  64. >other nonsense, most of which were shown incorrect, anyway. That's like if I
  65. >went to a doctor with my own ad-hoc diagnosis, and he prescribed a remedy for
  66. >what I think is wrong with me instead of diagnosing.
  67.  
  68. >Patient: ``Doctor, I think I need to strip a newline from a string to make my
  69. >program work!'' 
  70.  
  71. >Doctor: ``I won't bother looking at what your program is trying to do despite
  72. >that you brought it with you; you obviously know what you are doing, and just
  73. >need a little pointer. Here is a prescription for removing a newline that will
  74. >sometimes work...'' 
  75. >-- 
  76. It's a shame I didn't see the full original posting, but maybe your
  77. solution is 'bullshit' too.
  78. A long, long time ago, K&R taught me that the beauty in unix is
  79. simplicity: don't re-invent a tool that already exists.  If all the
  80. original author wants to do is read 2 (or more) files side by side,
  81. what's wrong with good old pr?
  82. or, getting fancier, and comparing them, sdiff?...depending on the
  83. situation, get nuts, use paste... join...
  84.  
  85. Getting raw side-by-side output from text files at the shell is as
  86. simple as:
  87.     pr -m file1 file2 ... 
  88. or
  89.     pr -t -m ....
  90. if you don't want the pr header.
  91.  
  92. If this requirement is within  C code where the multiple inputs
  93. screw up the ability to use pipes, then forgive me for not knowing all
  94. the facts. 
  95. But,
  96. The other response using strlen isn't 'wrong'; there are lots of
  97. ways to skin a cat.  I have yet to use a version of Unix that will
  98. blow up on forcing a null into a returned NULL pointer.
  99. For 18 years, I have coded scary stuff like 
  100.     *strrchr(buffer, '\n') = '\0'
  101. and have yet to have a problem.  Try it on your system.
  102. Any problems?
  103. The mere nature of the author's request would indicate that
  104. he is looking at text files, (what sense is there doing side-by-
  105. sides of binaries?)  So, why not a utility that works with, and 
  106. assumes, text?  Unix text files have \n terminators.  Correct me
  107. if I'm wrong.
  108.  
  109. So, why write a bunch of lines of _elegant_ code to simply
  110. clobber a newline? 
  111.  
  112. I also notice that your solution does not take into account any
  113. output formatting: what happens to the output from f2 when f1 is
  114. shorter that f2?  From what I see, it starts looking like output from 
  115. f1. 
  116.  
  117. Is your version really faster?  Does it really matter for the author's
  118. needs?  Is it easier to follow?  Is it smaller?  Easier to debug when
  119. buried in a few thousand lines of code?  By the way, isn't the stdio
  120. library's intent to create more efficient i/o?  Is getc/putchar really
  121. more efficient than fgets or fread?
  122.  
  123. I'm new to this group, and your type of response is kind of scary:
  124. does everyone here have a chip on their shoulder?
  125. Cut others a little slack!
  126.  
  127.